A database deployment infrastructure can be a service layer of a database management system that simplifies the deployment of database objects and other design time artifacts by providing a declarative approach for defining these design time artifacts and ensuring a consistent deployment into the database management system environment (DBMS), based on a transactional all-or-nothing deployment model and implicit dependency management. Such an approach can leverage capabilities of a modern high-speed DBMS, such as for example the HANA in-memory DBMS available from SAP SE of Walldorf, Germany, which can provide very high performance relative to disk-based approaches.
Using various customization-enabling integrated development environments (IDE), such as for example the HANA Studio available for use with the HANA IM-DBMS (available from SAP SE of Walldorf, Germany), a user may, using a group of design time artifacts, create information models, tables, landscapes, etc. on a different system or systems than that on which a DBMS is executed.
The design time artifacts used at the various levels of a database architecture (e.g. the tables in a physical layer; various joins, views, or other aggregations implemented in one or more logical layers; semantic objects in a semantic layer such as a calculation engine or the like; and application objects in an application layer) can include a variety of dependencies (e.g. an artifact can have one or more dependencies on other objects and can also be have other objects with dependencies on them. Not all dependencies between artifacts can be perceived simply by inspecting structural dependencies. For example, a statement in SQL (structured query language) or another special-purpose programming language for managing data of a DBMS can be used to generate a view or other data aggregation at the logical or physical table level of the database. Such statements are typically generated without knowledge of dependencies that may arise from other SQL statements or from actions occurring due to programming at other database levels. Without this knowledge, it is possible for design time artifacts of the database environment to be called in an order that leads to errors.